home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941221-19950208
/
000411_news@columbia.edu_Sat Feb 4 18:25:20 1995.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA05549
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sat, 4 Feb 1995 13:25:28 -0500
Received: by apakabar.cc.columbia.edu id AA00424
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 4 Feb 1995 13:25:26 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit and bad line conditions 2/2
Date: 4 Feb 1995 18:25:20 GMT
Organization: Columbia University
Lines: 50
Message-Id: <3h0gqg$d2@apakabar.cc.columbia.edu>
References: <3gtl0h$62h$2@mhadg.production.compuserve.com>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3gtl0h$62h$2@mhadg.production.compuserve.com>,
Hans Rehfeld <100125.3631@CompuServe.COM> wrote:
> We are using an IBM-PC MS-DOS Kermit V 3.12 (client) and a
> C-Kermit 5A(188), 23 Nov 92, OpenVMS VAX (server).
>
The current versions are 3.14 and 5A(190), respectively.
> Performing a transmission to a receiving Kermit via Modem
> with bad line quality results in the following error.
> Packet log of sending Kermit:
>
> Spack: ^A0 I~* @-#Y1~F!"*N^M
> Rpack: <Crunched packet>
> Spack: ^A0 I~* @-#Y1~F!"*N^M
> Rpack: ^A <Timeout>
> Spack: ^A0 I~* @-#Y1~F!"*N^M
> Rpack: ^A0 Y~4 @-#Y1~N'-U*^M
> Spack: ^A6 GI'REHFELD(xxxxxx '^M
> Rpack: ^A0 Y~4 @-#Y1~N'-U*^M
> ----------> The received packet above is not an ACK to the login
> packet, but is an ACK to the previously sent Init packet)
> Nevertheless the Kermit sends out the Send packet
> Spack: ^A0 S~* @-#Y1~F'"*^^M
>
Unfortunately, this can happen. The packet sequence number resets to
zero after each "transaction". The I-Y sequence is considered a
transaction, and the REMOTE LOGIN packet starts another transaction.
So in a case like yours, in which the ACK to the I packet is
transmitted more than once (due to timeouts or checksum failures) and
the second or subsequent ACK is delayed, and arrives after the G packet
is sent, it can indeed be misinterpreted as the ACK to the G packet.
But no harm is done, because any resulting "packet skew" will be
caught as the transaction proceeds.
> Rpack: ^A; EKUA-W-104, Login failure4^M
> Spack: ^A$ GL:^M
> Rpack: ^A# Y>^M
>
The standard C-Kermit server does not support the REMOTE LOGIN feature.
That is, the server will not log you in to VMS, and it does not even
recognize the REMOTE LOGIN packet. I must say I am somewhat mystified
at the "Login failure" message above, because the response should have
been:
Unimplemented REMOTE command
So I think somebody must have made some local changes to your version
of C-Kermit.
- Frank